10 research outputs found

    La Validation dans le Processus de DĂ©veloppement

    Get PDF
    International audienceThe amelioration of the quality of a system begins by the requirements elicitation. Our goal is to bridge the gap between requirements, those of the client, and the specification, this of the computer scientist. In this paper, we talk about the validation all along the development of a system, taking into account its requirements and its Event-B specification. The verification may also detect incoherences in the requirements. The Rodin platform is important all along to improve the quality and the documentation of the system, both of its specification and its development process. We illustrate our approach on the case study of an aircraft landing system.L'amélioration de la qualité d'un logiciel commence par l'expression de ses exigences en langage naturel. Notre objectif est de combler l'écart entre le cahier des charges, celui du client, et la spécification formelle, celle de l'informaticien. Dans ce papier, nous abordons la validation tout au long du processus de développement, en tenant compte des exigences et la spécification en Event-B du logiciel. La vérification peut aussi détecter des incohérences dans les exigences. La place des outils, notamment avec la plateforme Rodin, est importante au long de ce processus, améliorant sa qualité et sa documentation. Notre approche est illustrée par l'étude de cas d'un système de contrôle du train d'atterrissage d'un avion

    Articulation between definite and semi-definite activities in software development

    No full text
    Le développement de spécifications formelles correctes pour des systèmes et logiciels commence par l’analyse et la compréhension des besoins du client. Entre ces besoins décrits en langage naturel et leur spécification définie dans un langage formel précis, un écart existe et rend la tâche de développement de plus en plus difficile à accomplir. Nous sommes face à deux mondes distincts. Ce travail de thèse a pour objectif d’expliciter et d’établir des interactions entre ces deux mondes et de les faire évoluer en même temps. Par interaction, nous désignons les liens, les échanges et les activités se déroulant entre les différents documents. Parmi ces activités, nous présentons la validation comme un processus rigoureux qui démarre dès l’analyse des besoins et continue tout au long de l’élaboration de leur spécification formelle. Au fur et à mesure du développement, des choix sont effectués et les retours des outils de vérification et de validation permettent de détecter des lacunes aussi bien dans les besoins que dans la spécification. L’évolution des deux mondes est décrite via l’introduction d’un nouveau besoin dans un système existant et à travers l’application de patrons de développement. Ces patrons gèrent à la fois les besoins et la spécification formelle associée ; ils sont élaborés à partir de la description de la forme des besoins. Ils facilitent la tâche de développement et aident à éviter les risques d’oublis. Quel que soit le choix, des questions se posent tout au long du développement et permettent de déceler des lacunes, oublis ou ambiguïtés dans l’existant.The development of correct formal specifications for systems and software begins with the analysis and understanding of client requirements. Between these requirements described in natural language and their specification defined in a specific formal language, a gap exists and makes the task of development more and more difficult to accomplish. We are facing two different worlds. This thesis aims to clarify and establish interactions between these two worlds and to evolve them together. By interaction, we mean all the links, exchanges and activities taking place between the different documents. Among these activities, we present the validation as a rigorous process that starts from the requirements analysis and continues throughout the development of their formal specification. As development progresses, choices are made and feedbacks from verification and validation tools can detect shortcomings in requirements as well as in the specification. The evolution of the two worlds is described via the introduction of a new requirement into an existing system and through the application of development patterns. These patterns manage both the requirements and their associated formal specifications ; they are elaborated from the description of the form of the requirements in the client document. They facilitate the task of development and help to avoid the risk of oversights. Whatever the choice, the proposed approach is guided by questions accompanying the evolution of the whole system and makes it possible to detect imperfections, omissions or ambiguities in the existing

    Articulation entre activités formelles et activités semi-formelles dans le développement de logiciels

    No full text
    The development of correct formal specifications for systems and software begins with the analysis and understanding of client requirements. Between these requirements described in natural language and their specification defined in a specific formal language, a gap exists and makes the task of development more and more difficult to accomplish. We are facing two different worlds. This thesis aims to clarify and establish interactions between these two worlds and to evolve them together. By interaction, we mean all the links, exchanges and activities taking place between the different documents. Among these activities, we present the validation as a rigorous process that starts from the requirements analysis and continues throughout the development of their formal specification. As development progresses, choices are made and feedbacks from verification and validation tools can detect shortcomings in requirements as well as in the specification. The evolution of the two worlds is described via the introduction of a new requirement into an existing system and through the application of development patterns. These patterns manage both the requirements and their associated formal specifications ; they are elaborated from the description of the form of the requirements in the client document. They facilitate the task of development and help to avoid the risk of oversights. Whatever the choice, the proposed approach is guided by questions accompanying the evolution of the whole system and makes it possible to detect imperfections, omissions or ambiguities in the existing.Le développement de spécifications formelles correctes pour des systèmes et logiciels commence par l’analyse et la compréhension des besoins du client. Entre ces besoins décrits en langage naturel et leur spécification définie dans un langage formel précis, un écart existe et rend la tâche de développement de plus en plus difficile à accomplir. Nous sommes face à deux mondes distincts. Ce travail de thèse a pour objectif d’expliciter et d’établir des interactions entre ces deux mondes et de les faire évoluer en même temps. Par interaction, nous désignons les liens, les échanges et les activités se déroulant entre les différents documents. Parmi ces activités, nous présentons la validation comme un processus rigoureux qui démarre dès l’analyse des besoins et continue tout au long de l’élaboration de leur spécification formelle. Au fur et à mesure du développement, des choix sont effectués et les retours des outils de vérification et de validation permettent de détecter des lacunes aussi bien dans les besoins que dans la spécification. L’évolution des deux mondes est décrite via l’introduction d’un nouveau besoin dans un système existant et à travers l’application de patrons de développement. Ces patrons gèrent à la fois les besoins et la spécification formelle associée ; ils sont élaborés à partir de la description de la forme des besoins. Ils facilitent la tâche de développement et aident à éviter les risques d’oublis. Quel que soit le choix, des questions se posent tout au long du développement et permettent de déceler des lacunes, oublis ou ambiguïtés dans l’existant

    Articulation entre activités formelles et activités semi-formelles dans le développement de logiciels

    No full text
    The development of correct formal specifications for systems and software begins with the analysis and understanding of client requirements. Between these requirements described in natural language and their specification defined in a specific formal language, a gap exists and makes the task of development more and more difficult to accomplish. We are facing two different worlds. This thesis aims to clarify and establish interactions between these two worlds and to evolve them together. By interaction, we mean all the links, exchanges and activities taking place between the different documents. Among these activities, we present the validation as a rigorous process that starts from the requirements analysis and continues throughout the development of their formal specification. As development progresses, choices are made and feedbacks from verification and validation tools can detect shortcomings in requirements as well as in the specification. The evolution of the two worlds is described via the introduction of a new requirement into an existing system and through the application of development patterns. These patterns manage both the requirements and their associated formal specifications ; they are elaborated from the description of the form of the requirements in the client document. They facilitate the task of development and help to avoid the risk of oversights. Whatever the choice, the proposed approach is guided by questions accompanying the evolution of the whole system and makes it possible to detect imperfections, omissions or ambiguities in the existing.Le développement de spécifications formelles correctes pour des systèmes et logiciels commence par l’analyse et la compréhension des besoins du client. Entre ces besoins décrits en langage naturel et leur spécification définie dans un langage formel précis, un écart existe et rend la tâche de développement de plus en plus difficile à accomplir. Nous sommes face à deux mondes distincts. Ce travail de thèse a pour objectif d’expliciter et d’établir des interactions entre ces deux mondes et de les faire évoluer en même temps. Par interaction, nous désignons les liens, les échanges et les activités se déroulant entre les différents documents. Parmi ces activités, nous présentons la validation comme un processus rigoureux qui démarre dès l’analyse des besoins et continue tout au long de l’élaboration de leur spécification formelle. Au fur et à mesure du développement, des choix sont effectués et les retours des outils de vérification et de validation permettent de détecter des lacunes aussi bien dans les besoins que dans la spécification. L’évolution des deux mondes est décrite via l’introduction d’un nouveau besoin dans un système existant et à travers l’application de patrons de développement. Ces patrons gèrent à la fois les besoins et la spécification formelle associée ; ils sont élaborés à partir de la description de la forme des besoins. Ils facilitent la tâche de développement et aident à éviter les risques d’oublis. Quel que soit le choix, des questions se posent tout au long du développement et permettent de déceler des lacunes, oublis ou ambiguïtés dans l’existant

    Bridging the Gap Between Requirements Document and Formal Specifications using Development Patterns

    No full text
    International audienceGuaranteeing the correctness of critical and complex software and systems is a challenge that needs to be tackled right from the requirements engineering phase. This paper introduces two development patterns linked to the shape of requirements. The first one allows to automatically formalize a constraint and introduce it in an existing system. The second one is interested on requirements describing a sequence of operations. The verification activity is partly automated and the validation becomes easier to manage. The approach using these development patterns allow us an incremental development of formal specifications and their associated requirements, linked by a glossary. The case study of a hemodialysis system is used as a running example throughout this paper

    La validation dans les premières étapes du processus de développement

    No full text
    International audienceImproving the quality of a system begins by the requirements elicitation. Our goal is to take into account the validation since the understanding of the requirements and all along the development of their Event-B specification. Our challenge is to bridge the gap between requirements, those of the client, and the specification, that of the computer scientist. We make explicit the interactions between the requirements and the specification under construction. The validation is studied for formal models with regard to the requirements. The verification may detect incoherences and contradictions in both requirements and formal specification. The Rodin platform tools are important all along the development to improve the quality and the documentation of the system. Rodin and the ProR plugin allow us to manage the trace of the requirements and their specification. The documentation and the feedback of the different used tools for the validation and verification are available at any time of the development. We illustrate our approach to the case study of an aircraft landing system.L'amélioration de la qualité d'un système commence par l'expression de ses besoins en langage naturel. Notre objectif est de prendre en compte la validation dès la compréhension des exigences et tout au long du développement de la spécification en Event-B. Pour combler l'écart entre le cahier des charges et sa spécification formelle, nous explicitons les interactions entre ces deux mondes. La validation est étudiée pour les modèles formels relativement aux exigences. La vérification permet de détecter des incohérences et des contradictions dans le cahier des charges et dans la spécification Event-B. La place des outils disponibles, notamment avec la plateforme Rodin, est importante tout au long du développement, améliorant sa qualité et sa documentation. Rodin et le plugin ProR permettent de gérer la trace des besoins en lien avec la spécification en cours de construction. L'ensemble des documents disponibles et les retours des outils de validation et vérification sont disponibles tout au long du développement. Notre approche est illustrée par l'étude de cas d'un système de contrôle du train d'atterrissage d'un avion

    Du cahier des charges à sa spécification

    No full text
    International audienceLe cahier des charges est un document de référence tout au long du développement d'un système. Sa place commence par sa compréhension et sa structuration. Les liens entre ce document et la spécification en Event-B définie en termes de ses différents raffinements nous amène à utiliser des outils de vérification et de validation. Nous présentons quelques leçons sur le développement de la machine d'hémodialyse

    Formalisation des exigences pour décrire des systèmes corrects

    No full text
    International audienceImproving the quality of a system begins by their requirements elicitation: the challenge is to bridge the gap between the requirements of the client and their formal specification defined by the scientist. A first step consists on understanding and rewriting the existing requirements. Along the development process, we introduce formal terms in the requirements coming the formal specification and make explicit the interactions between them by a glossary. The trace of the requirements and their corresponding specification is managed and serves to simplify the activities of validation and verification. The validation is studied since the understanding of the first requirements and all along the development of their formal specification. The verification may detect imperfections like incoherences and ambiguities in both the formal specification and their corresponding requirements

    An In-depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities

    No full text
    International audienceNowadays, an increasing number of applications uses deserialization. This technique, based on rebuilding the instance of objects from serialized byte streams, can be dangerous since it can open the application to attacks such as remote code execution (RCE) if the data to deserialize is originating from an untrusted source. Deserialization vulnerabilities are so critical that they are in OWASP’s list of top 10 security risks for web applications. This is mainly caused by faults in the development process of applications and by flaws in their dependencies, i.e., flaws in the libraries used by these applications. No previous work has studied deserialization attacks in-depth: How are they performed? How are weaknesses introduced and patched? And for how long are vulnerabilities present in the codebase? To yield a deeper understanding of this important kind of vulnerability, we perform two main analyses: one on attack gadgets, i.e., exploitable pieces of code, present in Java libraries, and one on vulnerabilities present in Java applications. For the first analysis, we conduct an exploratory large-scale study by running 256 515 experiments in which we vary the versions of libraries for each of the 19 publicly available exploits. Such attacks rely on a combination of gadgets present in one or multiple Java libraries. A gadget is a method which is using objects or fields that can be attacker-controlled. Our goal is to precisely identify library versions containing gadgets and to understand how gadgets have been introduced and how they have been patched. We observe that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget. Furthermore, we noticed that among the studied libraries, 37.5% are not patched, leaving gadgets available for future attacks. For the second analysis, we manually analyze 104 deserialization vulnerabilities CVEs to understand how vulnerabilities are introduced and patched in real-life Java applications. Results indicate that the vulnerabilities are not always completely patched or that a workaround solution is proposed. With a workaround solution, applications are still vulnerable since the code itself is unchanged
    corecore